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APOLLO EXPERIENCE REPORT 

TEST AND CHECKOUT 

By Joseph E. Mechelay 
Lyndon B. Johnson Space Center 

SUMMARY 


Acceptance testing of Apollo spacecraft was conducted during manufacturing and 
assembly to determine conformity to design or specifications as a basis for acceptance. 
Testing at the launch site was conducted primarily to reverify performance of individ- 
ual launch vehicle stages and modules as received from the factory. Experience gained 
in dealing with many of the problems encountered during the Apollo Program in these 
areas of activity can be applied to future space flight programs. The following repre- 
sentative problem areas are discussed: checkout documentation, change implementa- 
tion, test configuration control, retest philosophy, destacking considerations, 
desirability of preinstallation acceptance tests, factory or field testing, use of nonflight 
equipment during checkout, desirability of propulsion system firing tests, vacuum test- 
ing considerations, crew equipment stowage tests, checkout of redundant functions, in- 
tegrated subsystem checkout, and checkout tolerances. 


INTRODUCTION 


The original Apollo philosophy was to provide flight-ready vehicles to the launch 
site. The reasons for establishing this objective were twofold: first, the early detec- 
tion of any hardware defects would result in an earlier resolution of any problem and, 
second, the factory would be better equipped to replace hardware. This philosophy was 
not completely realized because parts were not available and because subsequent iden- 
tification of requirements for some testing facilities required the installation of the 
parts at locations other than the factories for reasons of safety and economy. 

Acceptance testing of an Apollo spacecraft was conducted in conjunction with the 
manufacturing and assembly process. Testing was conducted at the launch site primar- 
ily to ensure that the performance of each subsystem had not degraded after factory 
checkout and to verify that the spacecraft/launch vehicle interface, launch team, and 
launch support equipment were ready. 

Problem areas encountered during the i^ollo Program are discussed in this re- 
port. In general, the areas discussed are within the scope of the spacecraft testing ac- 
tivities; however, several examples pertain to launch vehicle testing. Two approaches 
are taken in the discussion of the test and checkout activities. One approach is to state 



conditions or procedures that led to difficulties, then describe how the situation was 
rectified and recommend approaches for future programs. In other cases, recommen- 
dations are given for dealing with general problem areas without reference to specific 
problems, A glossary of special terms is given in appendix A. 


CHECKOUT DOCUMENTATION 


The preparation and control of test and checkout plans and the procedures for 
preparation and launch of Apollo spacecraft were specified in Apollo Program Direc- 
tive No. 26-B. This directive (reproduced in appendix B) required that the NASA 
Lyndon B. Johnson Space Center (JSC) (formerly the Manned Spacecraft Center (MSC)) 
prepare and approve a Test and Checkout Requirements Document and a Test and Check- 
out Specifications Document for submittal to the John F. Kennedy Space Center (KSC) 

4 months before delivery of a flight vehicle. These documents, in turn, provided the 
basis for the development of the test and checkout plans by KSC. 

Developing two separate documents for each vehicle resulted in the documents 
being organized such that cross-referencing was inconvenient. This led to misunder- 
standings between the design engineers and the test engineers concerning the compat- 
ibility of specifications and requirements. The problem was subsequently rectified by 
combining the documents into one so that a specification with an appropriate tolerance 
is given for each requirement (fig. 1). Future programs should follow the same ap- 
proach for specifying test and checkout requirements and tolerances. Other documen- 
tation schemes that have worked well and should be applied to future programs are as 
follows. 

1. The launch-site and factory test plans followed the internal indexing or num- 
bering system of the Test and Checkout Requirements Document. This consistency in 
numbering provided a convenient method of tracking requirements through all test 
documentation. 

2. One document was used as a basis for all vehicles. Then, at each revision, 
the requirements peculiar to vehicles that had been launched were deleted, and new re- 
quirements were incorporated. This technique not only reduced the paper volume but 
also kept the document current and minimized the amount of outdated material. An 
additional advantage was that continuity was maintained from vehicle to vehicle. 

3. Changes to the test documentation at KSC were made by test change notices 
(MSC Form 653, fig. 2), which described the present and proposed requirements and 
the justification for the change. All test change notices were approved by the Program 
Manager except in cases in which a delay in approval could have resulted in problems 
in meeting scheduled milestones or in cases where the change had been previously ap- 
proved through Configuration Control Panel/Configuration Control Board action. In 
these instances, the signature authority was delegated to the resident manager of the 
Apollo Spacecrit Program Office at KSC. The most significant aspect of the change 
system was the minimal amount of paperwork required to make a change. Any organi- 
zation could generate the change and submit it for approval immediately, if required. 
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TEST REQUIREMENTS AND SPECIFICATIONS 
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Figure 1.- Example of documentation of test requirements and specifications. 




TEST CHANGE NOTICE 



Figure 2. - Example of form used for test change notices. 




















CHANGE IMPLEMENTATION 


Hardware, software, and procedural changes requiring implementation during 
testing and checkout led to difficulties that could have been prevented if inadequacies 
had been recognized earlier. Examples of difficulties that were experienced are cited 
in the following paragraphs, and procedures to minimize delays and prevent accidents 
are recommended. 

Tests were disrupted when connectors were disconnected or ground support equip- 
ment (GSE) was shut off to permit a change. A technique was developed to alleviate 
problems of this nature by including periods in the test flow to incorporate blocks of 
changes. Use of this technique allowed vininterrupted testing and optimized work ac- 
complishment during modification periods. 

In some cases, malfunctions resulted when seemingly straightforward activities 
that should have been conducted in series were performed in parallel. During a modi- 
fication period, all activities should be controlled in a manner similar to that exercised 
during the test activity. This provides proper integration of all activities and ensures 
that systems safety is not compromised. 

Another difficulty occurred when all aspects of a major change were not incor- 
porated at one time, even though modification periods were in effect. The compatibility 
of a total change was normally proofed in an integrated systems ground test article, but 
a partial change was generally not tested in that program. Partial changes resulted in 
many aborted acceptance tests. A procedure should be implemented to flag partial 
change incorporation. A special assessment must be made to determine the effective- 
ness of tests that are conducted before completion of the total change. 

Another area of concern was the cancellation of a major change after it had been 
partially incorporated. In some cases, partially incorporated changes resulted in un- 
necessary equipment and circuits that could have caused flight failures. For example, 
electrical wiring installed as part of a major change and left installed after the major 
change was canceled resulted in an electrical shorting condition in the command mod- 
ule during one unmanned Apollo flight. An administrative procedure is required to pre- 
vent this type of occurrence. 

The converse of the preceding example also applies. Changes incorporated to 
deactivate equipment already installed require positive assurance that all interfaces 
have been deactivated. For electromechanical equipment, deactivating only the me- 
chanical functions could produce an electrical hazard or result in a flight failure. In 
the command module, a waste management system blower was deactivated by discon- 
necting and plugging the hardlines; however, electrical control of the blower was not 
changed or deactivated. The inadvertent activation of a switch caused the blower to 
operate against a deadheaded system, resulting in burning out the blower motor. The 
failure modes and effects analysis should be updated for each contemplated change to 
prevent situations such as this from occurring. 
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TEST CONFIGURATION CONTROL 


The vehicle configuration must be verified before any test is started. This veri- 
fication includes determining that the latest modifications have been incorporated; as- 
suring that all required components have been installed, required electrical connectors 
mated, and fluid lines connected; and assuring that cabin valves, circuit breakers, and 
switches are in proper positions. With respect to the GSE, the setup must be verified, 
the required fluid samples taken, and the switch/valve configuration verified. 

Once the test is started, rigid control must be exercised to maintain test disci- 
pline. This is accomplished by having approved procedures for test and by requiring 
documentation of discrepancies. (Documentation of checkout test anomalies proved to 
be very difficult to control during the ^ollo Program.) Usually, discrepant conditions 
should be analyzed before a test is continued, but this is not always possible. Discrep- 
ancies should be thoroughly documented as to how the vehicle/GSE is configured and how 
the problem manifests itself. The troubleshooting philosophy should be approved, and 
each step must be documented before its accomplishment. 

For example, during the prelaunch checkout of the ^ollo 16 spacecraft, a situa- 
tion occurred as a result of improper test configuration evaluation. During the trouble- 
shooting of a leaking quick-disconnect fitting, the pressure was vented from the GSE 
manifold to facilitate the valve changeout. However, the GSE/spacecraft configuration 
was such that venting of the manifold placed a negative pressure on the spacecraft burst 
disks. This negative pressure caused the burst disks to rupture and the spacecraft 
propellant tank bladders to collapse. As a result, the spacecraft had to be destacked 
so that the propellant tanks and integral bladders could be replaced. 


RETEST PHILOSOPHY 


There are many instances during the lifetime of a vehicle when connectors are 
disconnected, lines broken, components replaced, and similar actions taken. Occur- 
rences such as these cause loss of confidence in previously established test integrity; 
therefore, a retest philosophy and plan are required. System-level and vehicle-level 
acceptance tests are continually proofing the integrity of the entire system and/or 
vehicle. A plan that will set forth the philosophy and basic requirements for the re- 
establishment of proof of integrity is required in the early stages of checkout. The 
detailed retest plan will be a major undertaking in any future program. Such a plan 
was developed for the Apollo Program. This plan contained a matrix of all spacecraft 
connectors and showed where the integrity of each connector was verified during the 
checkout process. Many connectors were verified more than once, and this plan re- 
flected each verification. Because of this matrix, rapid determinations of retest re- 
quirements were easily made. In addition, when verification of connectors could be 
delayed until a later test date, valuable test time was saved because special retests 
were not required. The retest philosophy used in the Apollo Program is presented in 
the following subsections. This philosophy is recommended as a baseline for retest 
requirements. 
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General Retest Ground Rules 


Reverification may require additional testing or may utilize downstream testing, 
but the reverification should be accomplished before beginning the Flight Readiness 
Test. However, if troubleshooting or a replacement is required during the Flight 
Readiness Test, the reverification must be accomplished before completing the Flight 
Readiness Test by rerunning the appropriate test procedures sequences. The documen- 
tation that identifies and authorizes the operation resulting in invalidation of previous 
testing must include the specific retest requirements for reverification and the vehicle 
or test constraints. 

Retest procedures for each connector, control panel, and spacecraft component 
should be prepared before test as an adjunct to the standard operational test procedures. 
Retesting combinations of panels, components, and connectors will often result in some 
items being checked two or more times. The number of combinations involved is enor- 
mous. Constraints, switch matrices, and GSE usage, for example, have to be evalu- 
ated. Because of these factors, retest procedures cannot always be preplanned imless 
it is decided to repeat all basic operational checkout procedures, which would necessi- 
tate excessive retest time. It was often necessary in the Apollo Program to create re- 
test procedures in real time by combining parts of existing procedures and creating new 
ones as the case demanded. 


Retest Ground Rules for Electrical Assemblies 

Before a replacement assembly is installed, it must be preinstallation tested in 
accordance with existing specifications and time limitations to verify that the assembly, 
by itself, meets the required performance criteria. Any suspect or failed assembly 
removed from the spacecraft must be recycled through a preinstallation test and any 
additional bench-level test required to isolate malfunctions. Units that exhibit inter- 
mittent failures should not be reinstalled in the spacecraft until the cause of the failure 
is found and corrected. 

When an electronic assembly is replaced in the spacecraft by a different unit, all 
functional modes and all functional paths to and through the replacement assembly should 
be reverified and, in some instances, an end-to-end recalibration conducted. Nonsus- 
pect assemblies removed from the spacecraft to allow access to other equipment do not 
require bench-level testing before reinstallation. In this instance, an interface integrity 
test should be performed. All connectors that are demated must have continuity rever- 
ified after remating. After replacement or repair, continuity and electrical isolation 
should be reverified. 


Retest Ground Rules for Fluid and Mechanical Systems 

The replacement of components or the breaking of any fluid system requires, at 
a minimum, leak tests of the remated connections and cleanliness reverification of the 
reworked area. Functional verification in the spacecraft is required on replaced 
components. 
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Mechanical assemblies that have been functionally tested in the spacecraft and 
subsequently invalidated because of removal or replacement (or both) of a component 
should be reverified for fit and function. 


DESTACKING CONSIDERATIONS 


Destacking is the process of disassembling the stages or modules of a vehicle. 
Every destacking means possible vehicle damage, and retest is required to reestablish 
interface integrity. To maintain vehicle integrity in multimodule and multistage vehi- 
cles, destacking requirements should be minimized during the production acceptance 
test phase. The checkout flow and modification periods have to be optimized early to 
allow accomplishment of this objective. Too often, after the final acceptance tests of 
a vehicle in the factory, the vehicle was taken apart and reworked with the retest re- 
quirements passed on to the launch site, or the vehicle was destacked for shipment. 

At the launch site, some normal, noncontingent requirements may also dictate that the 
vehicle should be destacked. However, destacking should be avoided, and the total pro- 
duction test and checkout flow should result in a continuous buildup process terminating 
in a stacked vehicle. Test locales should be planned to minimize vehicle movement 
during checkout. 


DESIRABILITY OF PREINSTALLATION ACCEPTANCE TESTS 


A review of the Apollo preinstallation acceptance testing program disclosed that 
these tests often ’’crutched” inadequate vendor acceptance tests. The usual reason was 
thkt the test equipment, test procedures, test methods, and measurement systems used 
by the vendor generally differed from those used by the prime contractor. Under these 
conditions, if preinstallation acceptance tests are not conducted at the prime contrac- 
tor’s facility, problems will be encountered during vehicle-level tests. To resolve this 
problem, the vendor acceptance test equipment, procedures, and methods should be 
closely screened by the prime contractor and the responsible Government personnel to 
ensure that all requirements are acceptable. The vendor acceptance test would then 
serve as the preinstallation test. 


FACTORY OR FIELD TESTING 


The purpose of launch- site testing is to reverify performance of the individual 
stages and modules, as received from the factory, through the performance of inte- 
grated systems tests. These tests should be followed by buildup of the space vehicle 
and the verification of all functional interfaces between the stages and modules, such 
as the command and service module (CSM)/launch vehicle interface. No new or first- 
time tests should be performed on the individual stages or modules at the launch site. 
A flow diagram of the typical acceptance test activities for the CSM is shown in fig- 
ure 3, Typical launch-site test activities are shown in figure 4. 
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Figure 4. - The KSC test sequence. 


Flight-readiness firings and initial environmental tests should meet factory or 
special-test-site requirements. Complete functional and environmental tests of the 
various Saturn launch vehicle stages occurred before delivery of the launch vehicles 
to the launch site. However, static firings were not conducted on Apollo spacecraft 
propulsion systems because of the unique considerations resulting from the use of en- 
gines requiring hypergolic propellants. These considerations were, primarily, that 
the propulsion systems were difficult to purge and clean, the propellant caused corro- 
sion of system components, and the toxicity of the propellant presented a hazardous 
working condition. 

Two different vacuum- chamber tests were conducted on the Apollo spacecraft. 

For economy, the chambers were installed at KSC to reduce the requirements for con- 
struction of special facilities at the prime contractor's plants and to allow the vacuum 
chambers to be used for follow-on programs. Hazardous tests of manned modules, 
such as vacuum- chamber altitude simulations, should be conducted late in the test flow. 
At that time, the spacecraft modules are closer to flight configuration and greater as- 
surance of crew safety exists. 


USE OF NONFLIGHT EQUIPMENT DURING CHECKOUT 


In the Apollo Program, the use of nonflight equipment or substitute units during 
vehicle -level tests was a continuous source of discussion. These units were used when 
repeated testing or continuous cycling could be detrimental to critical flight items. For 
example, nonflightworthy reaction control engines were used for lunar module factory 
checkout. Substitute units may be required for use in place of sensitive electronic 
packages, especially those exhibiting a high change rate or a high failure rate. The 
same principle applies to guidance computer programs, or software, in which late 
availability could be a problem. 
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One argument against using nonflight hardware and software is that it may not 
represent the proper flight configuration. This is especially undesirable during a 
period in which change activity is high. This situation can be controlled with a rigid 
configuration management system that ensures change effectivity in the flight substi- 
tutes. Questions then will arise as to when in the test flow flight software should be 
used instead of test software and when substitute units should no longer be used. Apollo 
experience indicates that flight software can be incorporated into the spacecraft ex- 
tremely late in the launch- site checkout flow, provided that rigorous means of verifica- 
tion and reverification by an independent source have been used. 


DESIRABILITY OF PROPULSION SYSTEM FIRING TESTS 


The requirement for stage- or module-level propulsion system firing tests, often 
called flight-readiness firings, was another debatable issue. Every stage of the Saturn 
launch vehicle was subjected to an acceptance firing. It has been stated that a vehicle- 
level firing test additionally serves as a good vibration test for all vehicle equipment. 
This was true for the launch vehicle stages because the vibration environment during 
ground firing was more severe than that encountered during flight. However, this was 
not true for all spacecraft propulsion modules because of the lower thrust levels of 
some engines. This issue must be settled early in subsequent programs so that the 
vehicles can be built and the test flow planned to accommodate an acceptance firing. 

The Apollo lunar module ascent and descent engines were not capable of being 
fired at sea level conditions, and purging and cleanup requirements after firing of en- 
gines using hypergolic propellant would have decreased the confidence that the firing 
had produced. The Apollo service module engine also was not acceptance fired after 
installation because of the hypergolic considerations. However, production units were 
successfully fired during unmanned flights of both vehicles. An additional confidence 
firing of a nonflight production service module was performed. Satisfactory system 
performance was verified, but teardown of the system confirmed the existence of 
contamination and corrosion, thus reinforcing the decision not to perform ground 
firings of flight systems. Arguments against acceptance firings are the increased 
cost and the scheduling problems that would result. 


VACUUM TESTING CONSIDERATIONS 


In the Apollo Program, vehicle-level vacuum tests were conducted late in the 
test and checkout flow. An ’’all up” vehicle (a completely assembled CSM) was sub- 
jected to the vacuum environment to find faults that result from vacuum-induced expan- 
sion, and the complete environmental control system (ECS) was tested with the suited 
crewmen. Because vehicle-level tests were conducted, not all individual systems and 
equipment were previously exposed to a vacuum environment. It is recommended, how- 
ever, that vacuum testing of specific systems and types of equipment be accomplished 
before vehicle- level testing to minimize the possibility of problems in the later tests 
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and the resulting impact on schedules. As a minimum, the following categories of 
equipment should be individually tested in a vacuum environment. 

1. Items for which additional confidence is desired, such as life-support systems 
equipment 

2. Items that have marginal or questionable environmental sensitivity, such as 
electronic equipment packages containing soft potting 

3. Items that would require destacking or removal of a major structure for their 
replacement 


CREW EQUIPMENT STOWAGE TESTS 


Manned spacecraft test programs should include crew equipment stowage tests at 
the factory to ensure the adequacy of storage space and to check accessibility and utility. 
Because crew equipment is generally one of the last items to be delivered, the require- 
ment for these tests establishes firm goals for crew equipment delivery. The initial 
tests should be conducted by experienced crewmen to ensure that the stowage will be 
acceptable in the flight environment. 


CHECKOUT OF REDUNDANT FUNCTIONS 


Crew safety was enhanced by minimizing the number of single-point-failure possi- 
bilities in the Apollo spacecraft design. This was accomplished primarily by providing 
completely separate or alternate systems to perform the same function. If a mission 
function was critical, two identical primary paths were provided, and both paths usually 
operated simultaneously. Within each parallel path, additional series redundancy was 
usually provided when the paths contained critical parts and components. Parallel re- 
dundancy assured that a function was accomplished when required; series redundancy 
assured that a function would not be accomplished before it was required. 

In addition to the primary mode, a secondary or backup mode was provided for 
very critical functions. The backup mode was generally a manual and more direct 
method of accomplishing the mission function; that is, it bypassed some of the devices 
that had to operate in each of the primary paths. The backup mode generally did not 
operate simultaneously with the primary mode, and redundancy may or may not have 
been incorporated. 

An example is given for additional clarification. Escape-tower jettison was a 
mission function required in the manual launch sequence. The primary mode of tower 
jettison was ignition of the tower jettison motor and separation of the tower bolts. This 
was accomplished automatically by the mission sequencers. Full end-to-end parallel 
redundancy was provided from the initiating mechanism to the function-accomplishing 
mechanism. One of the parallel paths was called the primary path and the other the 
redundant path. The backup mode for tower jettison was initiated manually. A switch 
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was actuated that ignited the launch escape motor and separated the tower bolts. This 
use of more than one relay, either parallel- or series-installed, provided circuit 
redundancy. 

Three aspects of verifying proper operation of redundant functions and backup 
modes need to be considered; each usually requires a separate test and checkout 
method. The processes are as follows. 

1. The primary and redundant functions^ are tested in three steps in the space- 
craft. Each parallel path is tested individually, end to end, and the parallel paths are 
tested simultaneously in the third step. This three- step checkout does not test the 
backup mode. 

2. The backup mode is tested in one step, end to end. 

3. The previously described end-to-end tests verify the open (permissive) posi- 

2 

tion of the redundancy. To verify the closed position, each item is checked separately. 
This is a relatively easy task if test points are provided between each item. These test 
points, however, are frequently not designed into the equipment for spacecraft-level 
checkout, and a true test can only be made during component fabrication or assembly 
and checkout of the equipment before installation in the spacecraft. 

Adequate testing at the factories constitutes complete verification of all redundant 
functions (case 1) and all backup modes (case 2) and a partial verification of redundancy 
(case 3). The redundancy verification not accomplished at a spacecraft level must be 
identified. Checkout of the redundant functions at the launch site should be accomplished 
as late as is practical in the spacecraft flow and should include all the redundant and 
backup modes that can be assessed. 


INTEGRATED SUBSYSTEM CHECKOUT 


The initial lunar module checkout philosophy was to verify each subsystem indi- 
vidually before verification of the next subsystem. This process was extremely long 
and costly. To save factory test time and to use the GSE hardware and software capa- 
bilities to their fullest advantage, an integrated subsystem checkout concept was im- 
plemented. This concept allowed several subsystems to be under test simultaneously 
under overall control of a master test document. With this method, when checkout of 
one subsystem was constrained because of an anomaly, the checkout flow for the re- 
maining subsystems could continue. This philosophy did require considerable planning 


The term ’’primary and redundant functions” refers to the operation of both 
paths of a pair of similarly constructed primary paths used to accomplish a single 
mission function, 

2 

The term ’’redundancy” refers, in this sense, to the provision of two or more 
identical parts or components used in a primary or redundant function or backup mode 
path. 
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effort to optimize the testing, troubleshooting, repairs, and replacements and to reduce 
the number of test constraints. The end result was that the spacecraft delivery mile- 
stones were met with substantially less test time on the spacecraft than under the pre- 
vious system of testing each subsystem independently. 


CHECKOUT TOLERANCES 


Satisfactory performance of the ECS was difficult to verify during factory checkout 
of the first manned vehicle. An investigation revealed that the tolerance values being 
used for vehicle-level tests were those specified by the supplier for the individual com- 
ponents. The results were that many failures were being reported, components were 
being replaced unnecessarily, and the resulting retests were severely hampering the 
checkout flow. The tolerance being used did not take into account test configuration and 
GSE differences that did not permit measuring to these tight tolerances. Consequently, 
the tolerances were adjusted to the mission requirements and then narrowed from these 
values by a root- sum- square technique that accounted for GSE inaccuracies and space- 
craft hardware measurement tolerances. Subsequent vehicle checkout progressed sat- 
isfactorily and no flight failures that could be attributed to checkout tolerances being 
too broad have been observed. 


CONCLUDING REMARKS AND RECOMMENDATIONS 


Although Apollo test and checkout methods were based, to a large extent, on ex- 
perience gained from previous programs, many additional lessons were learned as the 
Apollo Program progressed. Some of the more significant aspects of Apollo acceptance 
testing and preflight checkout experience have been discussed, and recommendations 
for future programs are summarized here. 

1. The Apollo test documentation method of combining requirements and specifi- 
cations into a multiple- spacecraft document is practical and is recommended for future 
use. 


2. Rigidly controlled procedures are recommended for the incorporation and 
testing of hardware and software changes made during the acceptance testing and check- 
out process. In addition, vehicle/ support equipment configuration control and documen- 
tation control must be strictly adhered to during all test periods. 

3. A comprehensive retest plan is required during the early stages of checkout, 
delineating requirements for demonstration of vehicle integrity after replacements, 
modifications, repair, et cetera. Retention of the Apollo philosophy as a baseline for 
establishing retest requirements is recommended. 

4. Requirements for destacking of multimodule or multistage vehicles should be 
held to a minimum during the production acceptance-test phase. 

5. Consideration should be given to deleting preinstallation acceptance tests in 
favor of vendor acceptance tests. 
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6. Where feasible, new or first-time tests should not be performed on individ- 
ual stages or modules at the launch site; these tests should be conducted at the factory. 

7. The use of nonflight equipment for checkout should be discouraged. When 
substitutes are required, the design should duplicate the functional characteristics of 
the flight items. 

8. Where feasible, at least one propulsion system firing should be conducted 
on a flight-configured stage or module as a proof of the production, test, and checkout 
processes. 

9. Vacuum testing should be performed at the component (black box) or highest 
practical level of assembly on all flight equipment susceptible to failure under vacuum 
exposure. This should be performed before vehicle vacuum testing. 

10. A crew equipment stowage test should be conducted at the factory. 

11. Complete verification of all redundant functions and backup modes should be 
accomplished at the factory, and, to the extent possible, component redundancy should 
be verified. The redundancy verification not accomplished at the spacecraft level must 
be identified. Checkout of the redundant functions at the launch site should be accom- 
plished as late as is practical and should include all redundant and backup modes that 
can be assessed. 

12. Apollo factory experience indicates that parallel checkout of selected space- 
craft subsystems is a practical consideration and can decrease overall checkout time. 

13. Checkout tolerances should be based on mission requirements and should 
consider the accuracy of both the spacecraft and ground support equipment measuring 
systems. 


Lyndon B. Johnson Space Center 

National Aeronautics and Space Administration 
Houston, Texas, January 23, 1974 
914-11-00-00-72 
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APPENDIX A 
GLOSSARY 


All-up vehicle - A completely assembled module 

Bench-level testing - Testing performed on a component basis or module basis outside 
the spacecraft 

Failure mode and effects analysis - Analysis of failure modes and their effect on sys- 
tems and on mission performance 

Flight Readiness Test - Last major test conducted before the Countdown Demonstration 
Test to verify that all spacecraft systems are in a state of flight readiness; in- 
cludes systems compatibility during abort modes and during a normal mission 

Functional mode - The terminal activity or indication that is the end result of a trans- 
mitted signal or initiating force 

Functional path - One or more routes by which a transmitted signal or initiating force 
can be directed to accomplish a desired activity or indication 

Interface integrity - Completeness of mechanical, electrical, and functional mate of 
two or more modules or stages 

Software - Computer programing, test procedures 
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DATE 

OFFICE OF MANNED SPACE FLIGHT 

PROGRAM DIRECTIVE 

M-D MA 

litOO.135 

December 8, 1970 

(Project) 


APOLLO PROGRAM DIRECTIVE NO. 26B 
TO ; DISTRIBUTION FROM: 


ROCCO A. PETRONE 
APOLLO PROGRAM DIRECTOR 

SUBJECT: Addendm 1 to Apollo Program Directive No. 26B 

Preparation of Test and Checkout Plans and Procedures at KSC 

I. PURPOSE 

The purpose of this addendum is to require that proper levels of 
approval for hazardous test and checkout of troubleshooting pro- 
cedures be identified in KSC Operations Directives. 

II. Hazardous Operations Approval Requirements 

KSC Operations Directives shall identify approval levels for tests 
or troubleshooting procedures involving hazardous operations or test 
or troubleshooting procedures not previously verified at the launch 
or factory sites. 

III. Implement at ion 

The requirement established by this addendum is effective immediately 
and implementation is applicable to all missions. Copies of imple- 
menting instructions shall be forwarded to MA. 
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DATE 

OFFICE OF MANNED SPACE FLIGHT 

PROGRAM DIRECTIVE 

MA IUOO.O75 

(Project) 

December 6, 1967 


APOLLO PROGRAM DIRECTIVE NO. 26-B 
MA OO9-O26-IB 



SUBJECT: Preparation of Test and Checkout Plans and Procedures at KSC 


I. PURPOSE 

This Program Directive covers the preparation and control of test 
and checkout plans and procediures for the preparation and launch 
of Apollo-Saturn space vehicles at KSC. 

II, SCOPE 

This Directive defines the requirements, responsibilities and 
inter-center coordination necessary to the development, revision 
and execution of test and checkout plans and procedures for the 
preparation and launch of Apollo-Satum space vehicles at KSC. 

III. RESPONSIBILITY 

The Directors of KSC, MSC, and MSEC are responsible for taking ac- 
tion as necessary to implement this Directive. Responsibilities 
assigned in this Directive may be delegated except in instances 
where the delegation of responsibility shall be no lower than the 
level specified herein. 

IV. TIME COMPLIANCE 

This Directive is effective for all subsequent Apollo/Saturn mis- 
sions except that the use of standardized names for KSC Test and 
Checkout Plans and Test and Checkout Procedures shall be effective 
for AS-205 and AS-503 and subsequent missions. 

V. IMPLEMENTATION 


A. The Manned Space Flight Centers shall prepare directives to 
implement the responsibilities assigned herein and submit copies 
to Apollo Program Director. 

B. Any inter-center problem arising in the implementation of this 
Directive which cannot be resolved shall be brought to the 
immediate attention of the Apollo Program Director. 
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OFFICE OF MANNED SPACE FLIGHT 

PROGRAM DIRECTIVE 


M-D 


M 


lUOO.075 

(Project) 


December 6, 19^7 


VI. GENERAL 


A. Development organizations (MSEC and MSC) are responsible for 
defining specific test and checkout requirements that must be 
performed on flight vehicles at the factory prior to acceptance 
and at the launch site prior to flight. Test and checkout 
requirements to demonstrate the performance of ground support 
equipment provided by the development organization vhich is 
associated with factory acceptance and launch site preparation 
shaill be included. The test and checkout requirements shall 
clearly define what is to be tested. Test methods, hardware 
configuration, test sequence and other constraints shall be 
identified to the extent necessary to assure attainment of 
test objectives, protect hardware from damage and provide for 
the safety of personnel. 

B. The combined factory and launch site test and checkout require- 
ments shall provide an integrated flow of testing. The objec- 
tive of the integrated test flow shall be to permit verification 
of the functional performance of essential systems and their 
integration into the space vehicle without unnecessary repeti- 
tion of factory level testing. To the extent practicable, the 
overall test flow shall permit correlation of data between 
factory and launch site testing for critical flight hardware 
components. 

C. Development organizations are responsible for providing test 
specifications and criteria or limits including redline values 
and associated configuration constraints by which to judge 
acceptable performance of flight hardware and ground support 
equipment furnished by the development organization. 

D. The development orgaaizations use different titles and formats 
for Test and Checkout Requirements and Test Specification and 
Criteria documents. At the earliest time convenient without 
republishing existing documents these shall be renamed as the 
Test and Checkout Requirements Document and the Test and 
Checkout Specifications and Criteria Document. If desired, 
the later document may be included as a part of the Test and 
Checkout Requirements Document. 

E. MSC and MSEC shall prepare and approve Test and Checkout Re- 
quirements and Test and Checkout Specifications and Criteria 
Documents for the flight vehicles and GSE which they develop. 
Approved documents shall be provided to the launch organization 
(KSC) no later than four months prior to delivery of flight 
vehicles to the Cape. 
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PROGRAM DIRECTIVE 
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i 
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F. MSC is responsible for preparing flight crew procedures for 
use on launch day and during flight. These procedures and 
changes thereto shall be made available to KSC for use in pre- 
paring test and checkout procedures involving flight crew 
participation. 

G. The above documentation provides the framework within which 
the launch organization prepares test and checkout plans for 
integrating all test activities at the launch site and develops 
detailed test and checkout procedures for each test. 

VII. TEST AND CHECKOUT PLM 


*A. A test and checkout plan shall be prepared by KSC. It shall 
provide an outline for accomplishing center test and checkout 
requirements at the launch site and shall include any additional 
test requirements necessary to verify launch facility, inter- 
face and compatibility with the Mission Control Center - Houston 
and the Manned Space Flight Network, and launch crew readiness 
or satisfy range and safety requirements. 

B. The following information shall be included: 

1. A flow plan designating the sequence of tests to be 
performed. 

2. Identification of the facilities involved in the overall 
test flow. 

3. Specific outlines for each test including the following; 

a. Test title and procedure number, 

b. Test objectives. 

c. Test location and facility. 

d. Test description in sufficient detail to define the 
procedure in outline form, 

e. Flight hardware and GSE configuration requirements. 

f. Software requirements. 


^Denotes change. 
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lUOO.075 
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g. Significant support requirements. 

h. Identification of any hazardous operations. 

i. Safety requirements including any special equipment, 
personnel, procediores or training required for test. 

j. Identify organizations outside of KSC that will be 
involved. 

k. A cross reference to the development center test 
requirements where applicable. 

U. A detailed list of deviations from development center 

test requirements. 

VIII. TEST AND CHECKOUT PROCEDURES 


A. Test and Checkout Procedures shall be prepared by KSC. A 
Test and Checkout Procedure shall define the detailed step- 
by-step sequence of events in a specific test and shall be 
generated for each test during preparation and laxinch of 
flight vehicles. 

B. KSC and contractor responsibilities and interfaces in the 
preparation, revision and execution of Test and Checkout 
Procedures shall be clearly defined by a KSC Management 
Instruction or other suitable document approved by the KSC 
Director. This document shall designate the official, at an 
appropriately high level in the KSC organization, who is re- 
sponsible for determining which tests are hazardous. 

C. MSC and MSFC may exercise an option to review Test and Check- 
out Procedures as deemed necessary. Any recommended changes 
shall be provided to KSC no later than 15 days prior to the 
start of the test. 

D. MSC and MSFC shall establish a mechanism to process launch 
site recommended changes in factory testing. 

E. The following guidelines shall be used in the preparation, 
revision and execution of KSC test and checkout procedures. 

1. Factory or test site test and checkout procedures which 
have been approved by the development organization shall 
be used as a baseline in the development of Launch Site 
Test and Checkout Procedures. Whenever possible. Test 
and Checkout Procedures written for use in the factory 
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will be modified for use at the launch site to fit unique 
facility requirements, safety considerations, integrated 
space vehicle test requirements and to meet objectives 
in the test and checkout plan. 

2. MSC is required to deliver approved flight crew procedures 
to KSC at least Uo days prior to a test or checkout opera-- 
tion involving the flight crew (See paragraph IX, B-2). 
Flight Crew Procedures as approved and published by MSC 
shall be used by KSC when applicable in preparing those 
test and checkout procedures involving the flight crew. 

In any cases where incompatibility between test and check- 
out procedures and flight crew procedures exists, KSC 
will obtain MSC approval of the Test and Checkout 
Procedure. 

3. All Test and Checkout Procedures involving hazardous op- 
erations shall contain or provide specific reference to 
written instructions for identifying emergency situations, 
safing of hardware and implementing emergency actions re- 
quired to evacuate or safeguard personnel and combat or 
limit the extent of the damage should an emergency arise. 

Test and Checkout Procedures shall be standardized in 
regard to the following items. 

a. Major policy and procedure matters regarding prepara- 
tion, review, approval and change cycle. 

b. Control, approval level and documentation of trouble- 
shooting during the conduct of Test and Checkout 
Procedures . 

c. Extent of quality control participation and sign off 
during execution of Test and Checkout Procedures. 

d. Extent of safety and medical organization participa- 
tion. (See MI 8900.1) 

e. Recording and approval level for deviations encountered 
during implementation of Test and Checkout Procedures. 

f. Policy concerning multiple effectivity of Test and 
Checkout Procedures, 

g. Inclusion or exclusion of preparation steps in Test 
and Checkout Procedures. 
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h. Recording of OIS channels during execution of Test 
and Checkout Procedures. 

i. Appropriate use of wairning and caution notes. 

*5. Prior to publication of a test and checkout procedure (TCP) 
for: (a) operational checkout of flight hardware; (h) func- 

tional verification and operational control of GSE; and 
(c) operational instructions to service, handle, and trans- 
port end item flight hardware during prelaunch and launch 
operations; it shsJ-l be approved by the KSC Safety Office 
for assurance that operations are compatible with KSC 
Safety criteria KMI 1710.13 and use appropriate safety 
personnel, techniques, and equipment. 

*6. Prior to publication of a technical procedure to: (a) au- 

thorize work, (b) provide engineering instructions; and 
(c) establish methods of work control; and involving 
hazardous operations , it shall be approved by the KSC 
Safety Office for assurance that operations are compati- 
ble with KSC safety criteria KMI 1710.13 and use appro- 
priate safety personnel, techniques and equipment. 

7. Test and checkout procedures involving human test subjects 
shall be coordinated with medical personnel for assurance 
that potential risks to the health of test subjects are 
minimized. (See HMI 8900. l) 

8. Test and Checkout Procedures shall be provided to the 
KSC Launch Vehicle or Spacecraft Quality Surveillance 
Division for review and use in preparing for participation 
in test and checkout operations. 

9. Test and Checkout Procedures and changes thereto for tests 
involving flight crew participation shall have signatxire 
approval of MSC. 

10. Approved Test and Checkout Procedures shall be distributed 
one month prior to the date of the test, 

11. A Test and Checkout Procedure control system shall be 
established which places positive control over changes 
subsequent to the distribution of approved copies to the 
test team. Only those changes in spacecraft, launch vehi- 
cle or space vehicle test and checkout procedures which 
will improve safety or are mandatory because of late 
changes in hardware configuration shall be approved in 


*Denotes change. 
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the last seven calendar days before scheduled start of a 
test unless approved by the following organizational level 
for the test indicated. 

a. Launch Operations Manager 

(1) Flight Readiness 

( 2 ) Countdown Demonstration 

( 3 ) Countdown 

b. Test Supervisor 

( 1 ) CSM or LM altitude chamber tests in MSOB 

( 2 ) CSM or LM final integrated systems test in MSOB 

( 3 ) CSM or LM integrated test in VAB or on pad prior 

to mating with space vehicle 

{k) L/V overall tests 1 and 2 in VAB or on pad 

( 5 ) S/V overall tests 1 and 2 in VAB or on pad 

(6) S/C or L/V propellant loading on pad 

(7) S/V simulated flight in VAB or on pad 

(8) Pyrotechnic installation in VAB or on pad 

12. Revisions to Test and Checkout Procedures shall be pro- 
vided to test team members at least ^8 hours in advance 
of the start of the test. Waivers to this requirement 
shall be approved at the organizational level established 
by the KSC Director except that this approval cannot be 
delegated lower than specified in VIII E-11 above for the 
tests indicated. 

13. Prior to initiation of a test, briefings shall be con- 
ducted for all key members of the test team to review 
the sequence of test activities, the Test and Checkout 
Procedures and any hazardous operations or emergency 
procedures. 
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ik* Prior to initiating a test, a review shall he made of 

all open work recorded against the hardware to he tested. 

A determination shall he made that the hardware (includ- 
ing GFE) is properly configured and that the Test and 
Checkout Procedure, Flight Crew Procedure and hardware 
are compatible. This determination shall he recorded 
and approved hy KSC and contractor organizations involved 
in the test. The procedure for recording and the level 
of approval shall he as specified hy the KSC Director, 

For spacecraft hardware tests involving flight crew par- 
ticipation, this determination shall have signature 
approval of MSC. 

15. Approval to initiate non-hazardous tests shall he at the 
organizational level established hy the KSC Director, 

16. Approval to initiate any test involving a hazardous 
operation shall he at the organizational level established 
hy the KSC Director in accordance with VIII E-11 above. 

IT. The Director, MSC, and the Director, MSFC, shall delegate 
the authority either to KSC or to the appropriate official 
of their own organizations to approve real time deviations 
to Test and Checkout Procedures involving compromise in 
test and checkout req.uirements . 

18. Changes in flight hardware configuration, test and check- 
out requirements, or test and checkout specifications 
and criteria shall he approved hy MSC and MSFC for the 
spacecraft and launch vehicle respectively. 

19. The flight crew shall use Test and Checkout Procedures 
when participating in flight hardware tests at the launch 
site. Flight crews shall come under KSC control during 
the time they are actively participating in tests of flight 
vehicles except that the flight crew may take any action 
necessary for its safety. 

20. Deficiencies encountered hy the flight crew while par- 
ticipating in KSC tests shall he recorded and disposi- 
tioned using the same documentation system as that used 
hy the test team. 

21. KSC shall make an analysis of Test and Checkout Proce- 
dures deviations subsequent to completion of major tests 
for the purpose of reducing deviations in subsequent Test 
and Checkout Procedures. 
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22. Tests involving hazardous operations shall not be con- 
ducted unless communications are adequate to support 
emergency operations. 

IX. CEMER RESPONSIBILITIES 

A. MSEC and MSC are responsible for: 

1. Preparing an appropriate document which assigns respon- 
sibility for functions and actions contained herein. 

2. Establishing and maintaining test and checkout require- 
ments, test and checkout specifications and criteria, 
and launch mission riiles inputs which are necessary to 
ass-ure test and checkout and flight readiness. 

3. Providing signature approval on KSC test and checkout 
plans. 

U, Approving deviations or waivers to test and checkout re- 
quirements, test and checkout specifications and criteria, 
and launch mission rules specified in IX A-2 above. 

5. Participation in preparation, revision and execution of 
KSC Test and Checkout Procedures in accordance with 
Section VIII, 

6. Assuring that adequate testing is being accomplished 
without unnecessary overlap and duplication. 

7. Providing signature approval on KSC criteria for deter- 
mining hazardous operations. 

B. MSC is responsible for: 

1. Advising KSC in writing of tests requiring flight crew 
and/or flight control personnel participation. 

2. Providing approved flight crew procedures to KSC at 
least kO days prior to a test or checkout operation 
involving the flight crew. 

3. Providing signature approval on KSC Test and Checkout 
Procedures involving flight crew participation. 

H. Providing signature approval on pre-test reviews of 

spacecraft hardware (including GFE) and Test and Check- 
out Procedure compatibility for those tests involving 
flight crew participation. 
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C. KSC is responsible for: 

1. Preparing an appropriate document which assigns respon- 
sibility for functions and actions contained herein. 

2. Developing test and checkout plans as defined in Sec- 
tion VII at least one month prior to delivery of flight 
hardware for each mission. 

3. Securing MSC and MSFC signature approval on test and 
checkout plans and changes thereto before these documents 
are approved or implemented. 

U. Preparing, revising and executing Test and Checkout 
Procedures in accordance with Section VIII. 

5 . Providing Test and Checkout Procedures to MSC and MSFC 
one month prior to the start of a test and assuring 
expeditious distribution of changes thereto. 

6 . Securing MSC signature approval on Test and Checkout 
Procedures and changes thereto and the pre-test reviews 
of spacecraft hardware and test and checkout procedure 
compatibility for those tests in which the flight crew 
has a requirement to participate. 

7. Assuring that MSC flight crew and flight control person- 
nel are integrated into the KSC test team for those tests 
in which they have a requirement to participate. 

8 . Developing criteria for determining hazardous operations 
and securing signature approval of MSC and MSFC. 

9 . Making final determination that Test and Checkout Proce- 
dures are adequate, safe and in accordance with develop- 
ment organizations test and checkout requirements, test 
and checkout specifications and criteria, flight crew 
procedures and launch mission rules. 

10. Obtaining deviations and waivers from development organi- 
zations test and checkout requirements, test and check- 
out specifications and criteria and launch mission rules 
which will not be fulfilled. 
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